Network-introduced delays are amongst the most important network performance metrics as they directly impact several wide area network applications ranging from real-time applications such as VoIP, interactive network gaming, to time-critical financial applications and localization systems.
Thus, monitoring the performance of data transmission delay within networks must involve a detailed understanding of how and where these delays are introduced.
Within traditional TDM technologies, network delay is predictable as per the deterministic transition time across TDM switches (e.g. in term of number of system clock transitions). However, with the tremendous increase in bandwidth demand, TDM is progressively replaced by Packet Switch Networks (PSNs) where packet jitters, also called as packet delay variations (random processes essentially induced by packet queuing), make packet resident time within the network node (called as network node resident time from now on) unpredictable.
Accordingly, PSN network operators need more than ever tools to monitor network delay or network latency in order to be able to take appropriate actions (e.g. network redesign/reconfiguration) aiming at respecting the Service Level Agreements (SLAs) and correcting SLA violations in term of network delay/latency.
To address these problems, Network operators, generally, rely on various end-to-end time-delay measurement tools such as                the PING command defined over the Internet Control Message Protocol (ICMPv4-RFC 792 and ICMPv6-RFC4443) which allows for the measure of the end-to-end round-trip delay from a source to a destination host in an IP network;        the one-way delay measurement method described by RFC 2679. This method may require time synchronization depending on the network delay/latency value, the required precision of the measurement and on the clock accuracy at both ends;        the traceroute (or tracert) command allowing to determine the address of each network node (i.e. each network-layer device) along a network path from a source to a destination host. Traceroute also returns the end-to-end delays, respectively, from the source to each traversed node within the network path.        
However, these tools return the whole end-to-end delay without any precision on the network node resident time (or latency). In other word, the returned delay value by these tools is considered as a single unitary component, already including the network node resident time without any precision thereon.
The network-introduced delay may be broadly divided into:                network node resident time, notably comprising                    the time needed by a network node to process (processing delay) a packet and prepare it for (re)transmission. The processing delay is mainly function of the protocol stack complexity, of the computational power available (i.e. the available hardware) at each node and of the card driver (or interface card logic); and            the queuing delay, i.e. the total waiting time of packets within buffers of a network node before processing and/or transmission, which may depends on the details of the switching (or lower layer switches) of the network node                        the transmission delay: the time needed to transmit an entire packet (from first bit to last bit) or more basically a single bit from the output port of a first network node to the input port of a second network node.        
Accordingly, by returning the whole end-to-end delay in a single value without giving any details on its components, up-to-date end-to-end delay measurement tools do not allow the operator to figure out the network segment(s) or the network node(s) where corrective actions should be applied to solve the latency budget exceeding issue.
Yet another problem of the prior art is that existent network diagnostic tools do not permit to determine what fraction of the total transfer latency is due to network node resident time.
One object of the present invention is to address the above-noted and other problems with the related art.
Another object of the present invention is to pinpoint where dominant delays are introduced within a network path.
Another object of the present invention is to provide a fine-grained composition of the network-introduced delays.
Another object of the present invention is to propose a method that permits to determine the per-node latency.
Another object of the present invention is to provide a command which, by controlling the content of a probe message, provides a fine-grained picture of end-to-end delays that this packet undergo.
Another object of the present invention is to split the end-to-end delay into components distinguishing the nodes resident times along a path from a source to a destination within an IP network.
Another object of the present invention is to permit operators to make rapid and precise diagnostic of the SLA violation issue (quality of the committed service not respected) in term of network latency.
Another object of the present invention is to provide a diagnostic command that permit to accurately pinpoint the sources of important delays in Internet applications.
Another object of the present invention is to uncover dominant network hops introducing to most latency and being responsible for delay degradation.